Calling JSON.stringify() twice is wasteful. Cache the result and use it on line 730.

unfortunately, the message undergoes change in all the possible control flows between here and line 730, so cached value is unusable.

Another alternative is to delay this sanity check to as late as line 730 where there is already a stringification, don't know whether it can have side effects or not - thoughts please?

This will only guard against three input types: undefined, function and symbol. All other values either throw (e.g., any input that includes a BigInt) or the non-serializable part would be omitted or replaced with the string 'null' (with the exception of the object containing an toJSON function which returns undefined).

There are lots of inputs which would also be problematic which would not be caught here. I actually doubt that we really have to guard against anything else than undefined. So let's just use a simple type check instead of using JSON.stringify:

if (typeof message !== 'string' &&
    typeof message !== 'object' &&
    typeof message !== 'number' &&
    typeof message !== 'boolean') {
  throw new ERR_INVALID_ARG_TYPE(
    'message', ['string', 'object', 'number', 'boolean'], message);
}

The reason why I would do the check like this is that in the default case the message is either a string or an object. Other type checks would not be necessary anymore. While doing it the other way around would require to always check for undefined, bigint, symbol and function. The error message is also a bit clearer that way.

This will not guard against a weird toJSON function but that should be fine.

@BridgeAR - I followed your suggestions, PTAL.

This will only guard against three input types: undefined, function and symbol. All other values either throw (e.g., any input that includes a BigInt) or the non-serializable part would be omitted or replaced with the string 'null' (with the exception of the object containing an toJSON function which returns undefined).

There are lots of inputs which would also be problematic which would not be caught here. I actually doubt that we really have to guard against anything else than undefined. So let's just use a simple type check instead of using JSON.stringify:

if (typeof message !== 'string' &&
    typeof message !== 'object' &&
    typeof message !== 'number' &&
    typeof message !== 'boolean') {
  throw new ERR_INVALID_ARG_TYPE(
    'message', ['string', 'object', 'number', 'boolean'], message);
}

The reason why I would do the check like this is that in the default case the message is either a string or an object. Other type checks would not be necessary anymore. While doing it the other way around would require to always check for undefined, bigint, symbol and function. The error message is also a bit clearer that way.

This will not guard against a weird toJSON function but that should be fine.

ret can never be null. If null is passed through as message JSON.stringify() would return the string 'null'.

JSON.stringify() either returns undefined or a string or it throws.